fix: harden ImageMagick policy and install rsvg-convert (OC10-164) - #309

Summary

Follow-up to owncloud/core#41827 / #41828 (OC10-164, arbitrary file read/write via ImageMagick's MSL coder). That fix closes the code-level gap in Bitmap::getResizedPreview(); this PR closes the corresponding gap in the Docker image, matching the ticket's "Item A" recommendation.

Checked all four repos in the image chain (owncloud-docker/ubuntu → php → base → server, both v22.04 and v24.04) - none ship an ImageMagick policy.xml override or MAGICK_CONFIGURE_PATH. The product runs on whatever the OS imagemagick-6-common package defaults to.

Confirmed against the real published images (docker pull owncloud/server:11.0.0 / :10.16.4, not a reconstruction):

• Neither image's active policy denies the MSL/MVG/MSVG coders. Imagick->readImage("msl:...") executes unrestricted in both.
• librsvg2-common (the shared library) is installed but librsvg2-bin (which provides the rsvg-convert binary) is not. ImageMagick's delegates.xml routes decode="svg" to rsvg-convert; without the binary, it silently falls through to ImageMagick's own internal SVG/MSVG coder - the exact vulnerable path.

Changes

• v22.04/overlay/etc/ImageMagick-6/policy.xml and v24.04/.../policy.xml (new): deny the MSL, MVG, MSVG, EPHEMERAL, TEXT, SHOW, WIN, PLT, LABEL, CAPTION, PANGO coders and the URL/HTTPS/HTTP/FTP delegates. Deliberately does not touch PS/PDF/EPS/XPS or add a blanket delegate/coder deny-all - ownCloud's PDF and Postscript previews decode through the Ghostscript delegate, and upstream ImageMagick's own hardening advice warns that a deny-all breaks exactly that.
• Both Dockerfile.multiarch: add librsvg2-bin next to the existing librsvg2-common.

Side finding, not fixed here: the current 10.16.4 image's own OS-default policy already denies the PDF coder outright (confirmed: Imagick->readImage() on a real PDF throws "not allowed by the security policy `PDF'" in the actual running container) - so PDF preview generation is currently broken on that line already, independent of this change. 11.0.0's policy doesn't have that same denial. My new policy.xml does not deny PDF/PS/EPS/XPS, so shipping it has the side effect of fixing that pre-existing 10.16 defect rather than perpetuating it. Flagging in case an admin has already reported "PDF previews don't work" against 10.16 - this PR is likely the fix for that too, though I didn't chase why the two lines' packaged policies differ.

Test plan

Built v24.04/Dockerfile.multiarch locally and verified in the built image:

• Smoke test: php --version reports PHP 8.3
• rsvg-convert present on PATH
• Imagick->readImage("msl:...") blocked: "not allowed by the security policy `MSL'"
• The PoC payload (<svg><image xlink:href="MSL:...">) renders but does not execute the MSL script (no file written)
• An MVG image primitive referencing msl: is blocked
• A real PDF still reads successfully
• A legitimate well-formed SVG still reads successfully (via the rsvg-convert delegate)

v22.04/Dockerfile.multiarch needs a private Freexian mirror secret to build that isn't available in my environment, so I replicated its OS-level package set (imagemagick-6-common, librsvg2-common, librsvg2-bin, ghostscript - none of which come from the Freexian mirror) on a bare ubuntu:22.04 container with the same policy.xml overlaid, and reran the identical test suite above - same results, including the PDF-previously-broken-now-fixed side effect.